Data processing system utilising distributed ledger technology

ABSTRACT

A system includes a firewall server and a plurality of computing nodes hosting a private distributed ledger. The private distributed ledger includes user accounts having addresses on the private distributed ledger and a firewall management contract storing filter rule data associating the addresses of at least some of said user accounts with respective filter rules for handling requests for data stored on the private distributed ledger. The firewall server is arranged to receive a request for data stored on the private distributed ledger, indicating an address of a first user account. In response to receiving said request, the firewall server is arranged to send a query to the firewall management contract for first filter rule data associated with the address of the first user account, receive a response from the firewall management contract, and process the request for data in accordance with the response from the firewall management contract.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. application Ser. No.16/368,610, filed Mar. 28, 2019, which claims priority to EP ApplicationNo. EP18169341.7, filed Apr. 25, 2019, under 35 U.S.C. § 119(a). Theabove-referenced patent applications are incorporated by reference inits entirety.

BACKGROUND OF THE INVENTION

A distributed ledger is an electronic ledger in which stored data isreplicated between nodes of a network. A blockchain is an example of atype of distributed ledger. Distributed ledgers, and blockchains inparticular, employ decentralised trust mechanisms which negate the needfor a central administrator or centralised data storage, which haveresulted in distributed ledgers being employed as ledgers forcryptocurrencies.

In addition to cryptocurrency platforms, more sophisticated distributedledger platforms have emerged. Such platforms allow for smart contractsto be deployed on a distributed ledger. Smart contracts executed code inresponse to receiving a transaction from a user account, or a messagefrom another smart contract on the distributed ledger. The execution ofsmart contract code can cause changes to the state of the distributedledger. In the example of a blockchain, these changes of state areencoded within blocks of the blockchain, and effectively becomeimmutable by virtue of the decentralised trust mechanism of theblockchain. Examples of blockchain platforms on which smart contractscan be deployed are the Ethereum platform and various Hyperledgerplatforms.

It is claimed that the Ethereum blockchain platform is Turing-complete,such that in principle, smart contracts may be programmed to solve anyreasonable computing problem, provided that sufficient computingresources (for example, memory) are available. In order to avoid abusesof computational resources by poorly- or maliciously-programmed smartcontracts (for example, smart contracts with code that results ininfinite loops), a transaction or message that causes an Ethereum smartcontract to run code must be accompanied by a transfer of cryptocurrencyreferred to as Ether. In particular, if a user sends a request to asmart contract that will result in a change to the state of theblockchain, the user must send Ether from a user account to the smartcontract in order for the transaction to be stored on the blockchain. Bycontrast, if a user sends a request to a smart contract that will notresult in a change to the state of the blockchain (referred to as aconstant method), Ether may not be required.

Many distributed ledgers are public, such that any network user mayrequest a user account and thereby participate in the operation of thedistributed ledger. Due to typically large numbers of users,decentralised trust in public distributed ledgers can be very reliable.Data stored on public distributed ledgers may be accessed by any networkuser. An example of a public distributed ledger is the Ethereum mainchain.

Distributed ledgers may also be hosted on private networks, such thatusers must be able to access the private network in order to participatein the operation of the distributed ledger. In some cases, the nodes ofa private distributed ledger are operated by a single entity, such as acorporate entity, resulting in de facto centralised trust. Privatedistributed ledgers are often used for testing smart contracts beforedeploying equivalent smart contracts on a public distributed ledger. Forexample, a private Ethereum-based blockchain may be used to test smartcontracts that will later be deployed on the Ethereum main chain.

SUMMARY

According to various aspects of the present invention, there areprovided systems and methods for storing and processing data, inaccordance with the appended claims. Further features and advantages ofthe invention will become apparent from the following description ofpreferred embodiments of the invention, given by way of example only,which is made with reference to the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a schematic diagram of a system for storing and processingdata on a public blockchain.

FIG. 2 is a block diagram representing an application server in thesystem of FIG. 1.

FIG. 3 is a block diagram representing an asset contract stored on thepublic blockchain of FIG. 1.

FIG. 4 is a block diagram representing a control contract stored on thepublic blockchain of FIG. 1.

FIG. 5 is a flow diagram representing a routine for logging into theapplication server of FIG. 1.

FIGS. 6a and 6b is a flow diagram representing a routine for requestingdata from a public blockchain.

FIG. 7 schematically shows a screenshot from a user device logged intoan application server.

FIG. 8 is a flow diagram representing a routine for requesting acertification of evidence.

FIGS. 9a and 9b is a flow diagram representing a routine for performinga certification of evidence.

FIG. 10 is a flow diagram representing a routine for revoking acertification of evidence.

FIGS. 11a and 11b is a flow diagram representing a routine for deployinga control contract on a blockchain.

FIG. 12 is a schematic diagram of a system for storing and processingdata on a private blockchain.

FIG. 13 is a block diagram representing a firewall server in the systemof FIG. 12.

FIG. 14 is a block diagram representing an off-site application serverin the system of FIG. 12.

FIG. 15 is a block diagram representing a firewall management contractstored on the private blockchain of FIG. 12.

FIG. 16 is a flow diagram representing a routine for accessing datastored on a private blockchain.

FIG. 17 is a flow diagram representing a routine for processing datastored on a private blockchain.

FIG. 18 is a schematic diagram of a system for storing and processingdata on private and public blockchains.

FIGS. 19a and 19b is a flow diagram representing a routine for accessingdata stored on public and private blockchains.

FIG. 20 is a flow diagram representing a routine for issuing a proxycertification on a public blockchain.

DETAILED DESCRIPTION OF CERTAIN INVENTIVE EMBODIMENTS Public ChainSystem

There is provided a system for storing and processing data on adistributed ledger. The distributed ledger comprises user accounts andsmart contracts referred to as asset contracts, each asset contractcorresponding to an asset with which a user can be associated. In oneexample, an asset is an attribute of an individual, for example anattribute that the individual has demonstrated in a workplace scenario.An asset contract is arranged to store association data, the associationdata associating a user account with evidence data stored in a datastore, the evidence data indicating that the user is associated with theasset. In response to a request indicating the user account, the assetcontract is arranged to return data indicative of a data location in thedata store at which the evidence data is stored. In this way, users mayquery the asset contract and retrieve the evidence data from the datastore, in order to be able to verify whether or not the user is entitledto be associated with the asset.

In some examples, a user associated with a user account on thedistributed ledger may be permitted to certify association data, wherebyto verify that the evidence data is genuine and entitles an individualto be associated with an asset. In such a scenario, the user performingthe certification is referred to as a witness. In some examples,certifying the association data involves the witness retrieving the datafrom the data location indicated by the association data, and ifsatisfied by the retrieved evidence data, sending a request to the assetcontract to update the association data to indicate that the associationdata is certified. In a similar routine, a user may revoke acertification of association data if the user believes that thecertification was inappropriately issued.

In order for a user to be permitted to act as a witness and certifyevidence, the user may be required to have specific privileges and/or aminimum trust level. A trust level is a value assigned to a user thatallows the user to perform certain actions on the distributed ledger,such as certifying evidence data or revoking a certification of evidencedata, as will be described hereafter. In order to manage these trustlevels, in some examples the distributed ledger further comprisesanother smart contract, referred to as a control contract, storing trustlevel data indicative of trust levels of users. During a routine inwhich a user attempts to certify association data stored by an assetcontract, the asset contract sends a message to the control contract,requesting the trust level of the user. The asset contract then comparesthe trust level of the user with minimum required trust level for theasset contract in order to determine whether the user is permitted toact as a witness and certify the association data.

Associating trust levels with user accounts on a distributed ledger mustbe performed by a user with sufficient privileges. In some examples, auser may have privileges with respect to a particular asset contract,and may be able to associate an asset-specific trust level with a useraccount for that particular asset contract. In other examples, a singleentity may be responsible for adjusting global trust levels that applyto multiple asset contracts. Associating trust levels with user accountscontrasts with the ethos of typical applications of distributed ledgers,which aim to replace centralised trust completely with a decentralisedtrust model. In this example, decentralised trust is retained regardingtransactional changes to the state of the distributed ledger, butcentrally-managed trust levels and privileges are employed with respectto specific actions, for example the action of certifying associationdata. In other examples, trust levels may be acquired according to adecentralised trust model—for example users having sufficiently hightrust levels may be permitted to increase a trust level of another user.

FIG. 1 shows an example of a system for storing and processing data inaccordance with the present invention. The system includes a publicnetwork 101. In this example, the public network 101 is the Internet.The public network 101 contains computing devices acting as nodes tohost a public distributed ledger 103 (referred to hereafter as thepublic blockchain 103). The public blockchain 103 in this example is theEthereum main chain.

The system of FIG. 1 includes multiple user devices, including firstuser device 113 and second user device 115. In this example, first userdevice 113 and second user device 115 are desktop computers. Other userdevices may be laptop computers, tablet computers, smart phones, or anyother type of user device capable of communicating with an applicationserver, for example using HyperText Transfer Protocol Secure (HTTPS).First user device 113 is configured to communicate with an applicationserver 105. In some implementations of the present example, theapplication server is a cloud-hosted virtual application server, forexample a virtual application server provided by Amazon Web Services®(AWS). In other implementations, the off-site application server 105 isa physical server. The application server 105 is further configured tocommunicate with an evidence store 107, a taxonomy server 112, and anIdentity Provider (IdP) 116.

The application server 105 provides an application interface to firstuser device 113, and is configured to communicate with nodes of thepublic blockchain 103 by means of exchanging Remote Procedure Call (RPC)requests and responses. In this example, the application server 105 usesthe Ethereum JSON-RPC-2.0 protocol to communicate with nodes of thepublic blockchain 103. The Ethereum JSON-RPC-2.0 protocol provides adata-efficient communication mechanism that is suitable for invokingmethods on an Ethereum-based blockchain.

The application server 105 provides access management services on behalfof the users, including the user of first user device 113, which includemanaging Ethereum key pairs for users, and requesting and authenticatingaccess tokens from the IdP 116. In this example, access tokens are usedto provide identity information to network entities such as the taxonomyserver 112 on behalf of users, including the user of first user device113. The IdP 116 stores a list of users associated with accounts on thepublic blockchain 103, along with blockchain addresses of the associatedaccounts. In this example, the IdP 116 is hosted by a separate server.In other examples, an IdP is hosted by an application server providingaccess management services. The application server 105 is operable todeploy contracts on the public blockchain 103, and to make transactionalchanges to contracts stored on the public blockchain 103, as will bedescribed in detail hereafter.

One function of the application server 105 is to deploy a controlcontract on the public blockchain 103 on behalf of a user. A user whodeploys a control contract is referred to as the owner of the controlcontract. The owner of a control contract is the only user permitted toperform certain actions. For example, subsequently to deploying thecontrol contract, the owner may deploy asset contracts to be controlledby the control contract, as will be described in more detail hereafter.The owner may also register user accounts of new users with the controlcontract. In this example, registering a user account with the controlcontract includes storing identity verification data corresponding to anew user on the control contract. In this example, identity verificationdata includes a hash of identity data derived from identity materialsprovided by the new user, for example a passport number.

In this example, the owner may also alter global and asset-specifictrust levels associated with user accounts, along with other privilegessuch as the right to request certification of evidence data(canRequest), the right to certify evidence data (canWitness) or theright to revoke certifications of evidence data (canRevoke), each ofwhich will be described in detail hereafter.

The application server 105 maintains an Ethereum wallet such that Ethermay be provided when the application server 105 makes transactionalchanges to contracts stored on the public blockchain 103. The Ethereumwallet is associated with a blockchain address of an account controlledby the owner of the control contract.

As mentioned above, the application server 105 is also configured tocommunicate with the evidence store 107. In this example, the evidencestore 107 includes a virtual data store provided by AWS, and is furtherconnected to a node of a distributed data store configured using theInterPlanetary File System (IPFS) protocol. In this example, the node ofthe distributed data store is operated by the operator of theapplication server 105. The skilled person will appreciate that thisallows the operator of the application server 105 to maintain evidencedata in the distributed data store and to prevent it from being lost. Infurther examples, an evidence store may not be connected to a node of adistributed data store. In further examples still, an evidence storeincludes a local server and a local database.

The application server 105 communicates with a taxonomy server 112,which provides taxonomy services that include maintaining additionalmetadata corresponding to asset contracts, including a hierarchy ofassets, as will be described in more detail hereafter. The taxonomyserver 112 in this example is a GraphQL server.

Second user device 115 is configured with a browser-based DecentralisedApplication (DApp), which communicates with nodes of the publicblockchain 103 using the Ethereum JSON-RPC-2.0 protocol. Second userdevice 115 is further configured to communicate with the evidence store107. Second off-site user device 115 performs access management locallyusing a locally-managed wallet containing an Ethereum key pair andhaving associated Ether.

As shown in FIG. 2, the application server 105 stores a master controlroutine 201. The master control routine 201 is configured to callsubroutines including access management routines 203 and blockchainroutines 205. The access management routines 203 include identitymanagement routines 207. The master control routine 201 calls theidentity management routines 207 in order to request and authenticateaccess tokens from the IdP 116, and calls the blockchain routines 205 inorder to invoke methods on the public blockchain 103. The applicationserver 105 further stores a token authentication key 215, which is usedfor authenticating access tokens received from the IdP 116, as will bedescribed hereafter.

FIG. 3 shows an example of an asset contract 301 stored on the nodes ofthe public blockchain 103. The asset contract 301 contains assetcontract code 303 and asset contract storage 305. The asset contractstorage 305 includes an asset name 307, a unique asset identifier 309,and a blockchain address 311 of a control contract 401. The unique assetidentifier 309 in this example is distinct from the asset name 307 andfrom the blockchain address of the asset contract 301, the significanceof which will be discussed hereafter. The asset contract storage 305further includes certification structures 313. Each of the certificationstructures 313 includes a blockchain address of a user. A certificationstructure corresponding to a user is updated when the user seekscertification of evidence indicating that the user is associated withthe asset, and is further updated when a user is certified as beingassociated with the asset, as will be described in more detailhereafter.

The asset contract storage includes trust level data 315, which isindicative of minimum trust levels required by users to be able toperform methods on the asset contract. In this example, the assetcontract has a cTrust level, which indicates a minimum cTrust level thatmust be assigned to a user for the user to be able to certify evidencerelating to the asset, as will be described in more detail hereafter.

FIG. 4 shows an example of a control contract 401 stored on the nodes ofthe public blockchain 103. The control contract 401 contains controlcontract code 403 and control contract storage 405. The control contractstorage 405 includes, for users associated with accounts on the publicblockchain 103, the blockchain address of the user account and anassociated data structure for the user. The associated data structurefor the user includes identity verification data, which in this exampleincludes a hash of identity data provided by the user during an initialregistration process. Identity data may include, for example, a passportnumber or a driving license number for the user, along with other datasuch as the date of birth of the user. The associated data structure forthe user also includes data indicative of global and asset-specifictrust levels of the user. As described above, a trust level is a valueassigned to a user that allows the user to perform certain actions onthe public blockchain. In this example, the user has a global cTrustlevel and may also have asset-specific cTrust levels corresponding tocertain assets. These cTrust levels of the user may be compared with acTrust level of an asset as will be described in more detail hereafter.The associated data structure for each user may also include canRequest,canWitness, and canRevoke flags, which indicate that the user has theright to request certification of evidence data, to certify evidencedata, and to revoke certifications of evidence data, respectively, aswill be described hereafter.

The control contract storage 405 also includes, for each asset contractcontrolled by the control contract 401, the blockchain address of theasset contract. The control contract storage 405 further includes arecord 407 of registered private blockchains, the importance of whichwill be discussed hereafter with reference to a public/private chainsystem. Finally, the control contract storage 405 includes an owneraddress 409, which is the address on the public blockchain 103 of anaccount controlled by the owner of the control contract (the user whodeployed the control contract).

FIG. 5 shows an example in which a user of first user device 113 logsinto the application server 105. First user device 113 receives, atS501, credentials from the user. The credentials may include, forexample, a username and/or email address, a password, a secret, or theanswer to a secret question. In some examples, multi-factorauthentication may be used. First user device 113 sends, at S503, alogin request to the application server 105. The login request includescredentials received from the user at S501. In response to receiving thelogin request at S505, the application server 105 requests, at S507, anaccess token from the IdP 116. The IdP 116 receives the access tokenrequest at S509, and checks, at S511, whether the credentials are valid.If the credentials are valid, the IdP 116 looks up, at S513, ablockchain address of an account associated with the user. In thisexample each registered user of the application server 105 has anidentity mapped to a unique address on the public blockchain 103.

The IdP 116 generates, at S515, an access token. In this example, theaccess token is a JavaScript Object Notation Web Token (JWT). The JWTincludes header, payload, and signature fields. The IdP 116 uses aprivate key to generate the signature of the JWT by applying a hashingalgorithm to data including the cryptographic key and a concatenation ofthe header and the payload. In this example, the HMAC-SHA256 (Hash-basedMessage Authentication Code—Secure Hashing Algorithm, 256 bit) algorithmis used. In other examples, other hashing algorithms may be used. Insome examples, the hashing algorithm is specified in the header of theJWT. In this example, the payload field includes the blockchain addresslooked up at S513. In other examples, the payload field of the JWTincludes data representing the identity of the user of first user device113. The application server 105 and the taxonomy server 112 maintaintoken authentication keys corresponding to private keys used by IdP 116to generate the JWT. In this example, the token authentication key 215is a public key corresponding to the private key used by the IdP 116 togenerate the JWT. In other examples, a token authentication key may be aprivate key identical to the private key used to generate an accesstoken.

The IdP 116 sends, at S517, a token response to the application server105. If the credentials received at S501 are valid, the token responseincludes the access token generated at S515. If the credentials receivedat S501 are not valid, the token response indicates that the credentialsare not valid. The application server 105 receives the token response atS519.

If the application server 105 receives an access token from the IdP 116,the application server 105 authenticates, at S521, the access token. Asmentioned above, the application server 105 maintains the tokenauthentication key 215 corresponding to the cryptographic key used bythe IdP 116 to generate the signature of the access token, and thereforeby applying the same hashing algorithm to the concatenation of theheader and payload of the access token, the application server 105 isable to verify the signature and hence verify that the access token wasgenerated by the IdP 116 and has not been modified (for example, by amalicious third party).

The application server 105 sends, at S523, a login response to firstuser device 113. If the application server 105 receives a valid accesstoken at S519, the login response indicates that the login issuccessful. If the application server 105 does not receive a validaccess token at S519, the login response indicates that the login isunsuccessful. First user device 113 receives the login response at S525.

In the example described above, the IdP 116 maintains a list of usersassociated with accounts on the public blockchain 103, along withblockchain addresses of the associated accounts, which allows the IdP116 to generate an access token with a payload containing a blockchainaddress of a user. In other examples, an application server may insteadstore a list of users associated with accounts, along with blockchainaddresses of the associated accounts. In such an example, theapplication server may authenticate an access token received from an IdP116, and if the access token is successfully authenticated, may thenlook up an associated blockchain address.

FIG. 6 shows an exemplary method in which the application server 105requests data stored on the public blockchain 103 on behalf of a user offirst user device 113. Prior to the routine of FIG. 6 taking place, theuser requesting data is authenticated according to the routine of FIG.5. In this example, the user requests data corresponding to assetsassociated with asset contracts controlled by the control contract 401on the public blockchain 103, as well as data indicating users that areassociated with those assets. The application server 105 requests, atS601, asset contract addresses from the control contract 401 stored onthe public blockchain 103. In this example, the request is in the formof an RPC request. Specifically, the RPC request is an EthereumJSON-RPC-2.0 request sent to one of the nodes of the public blockchain103, specifying the address of the control contract 401 as a recipientaddress, and operable to invoke a constant method on the publicblockchain 103. Unlike transactional methods, constant methods do notcause a change to the state of a blockchain.

As discussed above with reference to FIG. 4, the control contractstorage 405 includes the addresses of asset contracts stored on thepublic blockchain 103. In response to receiving, at S603, the requestfor asset contract addresses, the control contract 401 sends an RPCresponse, at S605, to the application server including addresses ofasset contracts stored on the public blockchain 103. The applicationserver 105 receives the RPC response including the addresses of theasset contracts at S607. The application server 105 requests, at S609,asset data from each of the asset contracts with addresses stored in thecontrol contract storage 405. Specifically, the application server 105sends, for each of the asset contracts, an RPC request specifying theasset contract address as a recipient address. In this example, therequested asset data includes the name of the asset, and a uniqueidentifier for the asset. In response to receiving a request for assetdata, each asset contract sends asset data to the application server atS611.

Having received asset data from each of the asset contracts withaddresses stored on the control contract 401, the application server 105requests, at S613, taxonomy data from the taxonomy server 112. Thetaxonomy server 112 receives, at S615, the request for taxonomy data andsends, at S617, taxonomy data to the application server 105. Thetaxonomy data includes additional metadata corresponding to the assetcontracts. In this example, the taxonomy data includes metadata defininga hierarchy of assets corresponding to the asset contracts. In responseto receiving the taxonomy data at S619, the application server 105builds, at S621, a catalogue of assets using the taxonomy data and theasset data received from the asset contracts.

The application server 105 queries the public blockchain 103, at S623,for certification events. Certification events are generated each time awitness with an appropriate cTrust level certifies evidence dataindicating that a user is associated with an asset, as will be describedin detail hereafter. The skilled person will be aware that eventsgenerated on an Ethereum-based blockchain are conveniently indexed forsearching and filtering. In this example, the certification eventsreturned in response to the query are filtered according to the publicblockchain address associated with the user to which the data requestpertains, such that only certifications corresponding to that user arereturned. The certification events are also filtered according to thepublic blockchain address of the asset contract to which thecertification event relates.

The application server 105 queries the public blockchain 103, at S625,for revocation events. Revocation events are generated each time a userwith appropriate privileges revokes a certification of evidence.Revocation will be discussed in detail hereafter. In this example, therevocation events returned in response to the query are filteredaccording to the public blockchain address associated with the user towhich the data request pertains, such that only revocation eventscorresponding to that user are returned.

The application server 105 decorates, at S627, the catalogue of assetsbuilt at S621, using the received certification events, and the receivedrevocation events. Decorating the catalogue includes incorporating theinformation indicated by the certification and revocation events, suchthat entries of the catalogue corresponding to assets also indicatewhether the evidence has been certified with regard to the asset andwhether such a certification has subsequently been revoked. Theapplication server 105 sends the decorated catalogue of assets to firstuser device 113 at S629.

In the example described above, a current user of first user device 113requests data corresponding to assets with which the current user isassociated. In other examples, a current user may request datacorresponding to assets with which a different target user isassociated. In these examples, the current user selects the target userfrom the list of users maintained by the IdP 116. In these examples, thereturned certification and revocation events are filtered according tothe different target user.

In the example above, a user logs into the application server 105 withfirst user device 113 in order to access data stored on the publicblockchain 103. In another example a user accesses data stored on thepublic blockchain 103 using second user device 115 using a browser-basedDApp. In this example, steps performed by the application server 105 inFIG. 6 are performed by the second user device 115 using thebrowser-based DApp, but the browser-based DApp may not have access tothe taxonomy server 112 and may therefore not receive taxonomy data inorder to build a catalogue of assets, including an asset hierarchy andadditional metadata corresponding to asset contracts, as describedabove. In a further example still, a user device running a browser-basedDApp may access a taxonomy server in order to receive taxonomy data.

FIG. 7 schematically shows an example of a screenshot taken from theuser device 113, having logged into the application server 105 anddownloaded an asset catalogue as described above with reference to FIG.6. The screenshot includes a navigation bar including two menu items.The first item, entitled “Catalogue”, navigates to the catalogue as seenin the screenshot. In this example the catalogue includes two dropdownmenus entitled “Future workforce model” and “Productivity”, as definedby taxonomy data received from the taxonomy server 112. Each of thedropdown menus includes three items. Each item corresponds to an assetassociated with an asset contract on the public blockchain 103. The userJohn Doe is yet to be certified for most of the items, and may select“Request certification”, which will initiate a routine equivalent tothat of FIG. 8 below. The user John Doe has already been certified forthe asset “Bravery”, and may select “View certification” in order toview the certification, including previously-uploaded evidenceassociated with the certification.

The navigation bar in FIG. 7 further includes a menu item entitled“Pending certifications”, which navigates to a list of pendingcertification requests which the user John Doe may certify. In order forthe user to view the list of pending certification requests, theapplication server 105 sends an RPC request to each asset contractlisted by the control contract 401, requesting pending certificationrequests. Pending certification requests are indicated by certificationstructures stored on the asset contracts, such as the certificationstructures 313 stored by asset contract 301.

FIG. 8 shows an exemplary method in which a user requests certificationof evidence data. In this example, the evidence data indicates that auser of first user device 113 is associated with an asset correspondingto the asset contract 301 stored on the public blockchain 103. Firstuser device 113 receives, at S801, the evidence data. In this example,the evidence data includes a digital photograph of a certificate oftraining issued by an employer. In this example, first user device 113receives the evidence data via an email sent by the employer to theuser. In other examples, a user may upload evidence data to a userdevice, or may generate evidence data, for example by taking aphotograph of evidence using a camera of the user device. First userdevice 113 uploads, at S803, the evidence data to the evidence store107.

Having uploaded the evidence data to the evidence store 107, first userdevice 113 sends, at S805, a request to the application server 105 forthe evidence data to be certified. The request for certificationincludes data indicating a first location at which the evidence data isstored, and data indicating the asset to which the evidence relates. Inthis example, the request includes a URL corresponding to a location ina virtual AWS database. The application server 105 receives the requestat S807.

The application server 105 retrieves, at S809, the evidence data fromthe evidence store, and sends, at S811, the evidence data to a node of adistributed data store configured using the IPFS protocol. The evidencedata is stored in the distributed data store. The application server 105then sends, at S813, an RPC request to the asset contract 301 includingdata indicating a location in the distributed data store at which theevidence data is stored. In other examples, the steps S809 and S811 areomitted, and the RPC request instead indicates a first location at whichthe evidence data is stored, for example on a virtual data store or aphysical database. In some such examples, the evidence data is alreadyavailable prior to a user requesting certification (for example, theevidence may be a video uploaded on YouTube®). In such an example, stepS803 is omitted.

The RPC request sent at S813 causes a transaction leading to a change ofstate of the public blockchain 103, and therefore requires Ether to besent from an account on the public blockchain 103. In this example, theaccount is associated with an Ethereum wallet maintained by the owner ofthe control contract 401.

The public blockchain 103 receives, at S815, the RPC request indicatingthe location in the distributed data store at which the evidence data isstored. The RPC request causes the asset contract 301 to checks, atS817, whether the user is assigned a canRequest privilege. In order tocheck whether the canRequest privilege has been assigned, the assetcontract 301 sends a message to the control contract 401, causing thecontrol contract 401 to send a message to the asset contract 301indicating whether the canRequest privilege has been assigned to theuser. If the canRequest privilege has been assigned to the user, thecertification structure corresponding to the user is updated at S819. Inthis example, the asset contract 301 does not have a certificationstructure corresponding to the user prior to the routine of FIG. 8taking place, and updating the certification structure includesgenerating the certification structure. The certification structure isupdated to associate the evidence data with the user. In particular, thecertification structure is updated to indicate that evidence data hasbeen uploaded relating to the asset, and further to indicate thelocation in the distributed data store at which the evidence data isstored.

In another example, steps S801 to S813 are carried out by second userdevice 115 using a browser-based DApp, rather than being carried out bythe application server 105. In this example, second user device 115maintains an Ethereum wallet such that Ether may be available for makingtransactional changes to the public blockchain 103.

FIG. 9 shows an exemplary method in which evidence data is certified bya witness using first user device 113. In this example, prior to theroutine of FIG. 9 commencing, a user requests certification of user datausing the routine of FIG. 8, and therefore a certification structure ofasset contract 301 associates the evidence data with the user whorequested the certification of evidence data. The evidence dataindicates that a user is associated with an asset corresponding to theasset contract 301 stored on the public blockchain 103. In this example,the witness is a user who is assigned a global cTrust level that atleast as high as the cTrust level of the asset to which the evidencerelates, and is further assigned the canWitness privilege, whichtogether permit the witness to certify evidence relating to the asset.In other examples, a witness may have a global cTrust level that islower than the cTrust level of an asset, but has an asset-specificcTrust level that is at least as high as the cTrust level of the asset,which similarly permits the witness to certify evidence relating to theasset.

In this example, the witness logs into the application server 105 withfirst user device 113 using the login routine of FIG. 5. The applicationserver 105 is therefore in possession of the address of an account onthe public blockchain 103 associated with the witness. In advance of theroutine of FIG. 9 taking place, the application server 105 queries theasset contracts stored on the public blockchain 103 for pendingcertification requests, such that the witness is able to view a list ofpending certification requests.

In this example, the witness is physically approached by the userseeking certification of evidence. The user provides the witness withidentity materials, for example a passport, and evidence materialscorresponding to the asset to which the certification request relates.The witness enters identity data derived from the identity materialsinto the first user device 113. In this example, the identity dataincludes the passport number and date of birth of the user seekingcertification of evidence. The application server receives, at S901, theidentity data from first user device 113. The application server 105computes, at S903, a hash of the identity data. In this example, theHMAC-SHA256 algorithm is used to compute the hash. In other examples,other hashing algorithms may be used. In some examples, a user device ofa witness computes a hash of the identity data, and sends the computedhash to an application server.

Having computed a hash of the identity data, the application server 105sends, at S905, an RPC request to the control contract 401 stored on thepublic blockchain 103. In this example, the RPC request is an EthereumJSON-RPC-2.0 request operable to invoke constant methods on the publicblockchain 103. The RPC request includes the blockchain address of theaccount associated with the user seeking certification of evidence, anda request for identity validation data. As discussed above, the controlcontract 401 stores identity validation data for users associated withaddresses on the public blockchain 103, including a hash of identitydata provided by the user during an initial registration process. Thecontrol contract 401 receives, at S907, the request for identityvalidation data, and sends, at S909, identity validation data to theapplication server 105. The application server 105 receives the identityvalidation data at S911. The application server 105 validates, at S913,the identity data received at S901. In this example, validating theidentity data includes comparing the hash computed at S903 with the hashincluded within the evidence validation data received at S911.

Having validated the identity data, the application server sends, atS915, an RPC request to the asset contract 301, which corresponds to theasset for which evidence is to be certified, requesting the location ofthe evidence data to be certified. As discussed above, the assetcontract 301 stores certification structures 313 indicating the locationof evidence data. Having received, at S917, the request for the locationof evidence data, the asset contract 301 sends, at S919, data indicatingthe location of the evidence data. The application server 105 receives,at S921, the data indicating the location of the evidence data, andretrieves, at S923, the evidence data. The application server 105 sends,at S925, the evidence data to first user device 113.

The witness checks the evidence data and decides whether to certify theevidence data. In this example, checking the evidence data includescomparing the evidence data with the evidence materials provided by theuser. If the witness decides to certify the evidence data, first userdevice 113 sends a request to the application server 105 indicating thatthe evidence data is to be certified. The application server 105receives, at S927, the request from first user device 113. Theapplication server 105 sends, at S929, a certification attempt to theasset contract 301 in the form of an RPC request. The RPC request causesa transaction leading to a change of state of the public blockchain 103,and therefore requires Ether to be sent from an account on the publicblockchain 103. In this example, the account is associated with anEthereum wallet maintained by the owner of the control contract 401. Thecertification attempt is received, at S931, at the asset contract 301.Having received the certification attempt, the asset contract 301checks, at S933, the cTrust level of the witness, and further checks, atS935, whether the witness is assigned the canWitness privilege. In orderto check the cTrust level of the witness and whether or not the witnessis assigned canWitness privilege, the asset contract 301 sends a messageto the control contract 401, causing the control contract 401 to send amessage to the asset contract 301 indicating a global cTrust level, andan asset-specific cTrust level, of the witness, along with an indicationof whether the canWitness privilege has been assigned to the witness. Ifeither the global cTrust level of the witness, or the asset-specificcTrust level for the witness, is at least as high as the cTrust level ofthe asset corresponding to the asset contract 301, and the canWitnessprivilege has been assigned to the witness, the witness is permitted tocertify evidence data indicating that the user is associated with theasset.

If the witness is permitted to certify the evidence, the asset contract301 sets, at S937, a certification flag in the certification structurecorresponding to the user. The asset contract 301 generates, at S939, acertification event on the public blockchain 103. Certification eventsare used by the application server 105 to decorate catalogues of assetsprovided to users, as described above with reference to FIG. 6.

In the example of FIG. 9, a witness logs into the application server 105with first user device 113 in order to perform a certification evidencedata. In another example, a witness performs a certification of evidencedata using second user device 115 using a browser-based DApp. In thisexample, the steps performed by the application server 105 in FIG. 9 areperformed by second user device 115. Accordingly, second user device 115maintains an Ethereum wallet such that Ether may be available for makingnecessary transactional changes to the public blockchain 103.

In some examples, a witness may certify evidence data without validatingidentity data. This may be suitable, for example, for assets having arelatively low value. In such cases, the steps of S903 to S913 may beomitted from the routine of FIG. 9. Furthermore, in some examples, awitness may not be approached physically by a user, and may simplyperform the certification of evidence data based on viewing the evidencedata alone, without ever seeing the corresponding evidence materials.The decision as to whether a witness needs to view evidence physicallywill depend on the nature of the asset and the evidence. In someexamples, the decision is at the discretion of the witness.

In the present example, only one certification may be performed for eachcertification request, even if a first certification is subsequentlyrevoked, as will be described in detail below.

FIG. 10 shows an example in which a user of first user device 113revokes a certification of evidence data, the evidence data indicatingthat a user is associated with an asset corresponding to the assetcontract 301. In this example, the user logs into the application server105 with first user device 113 using the login routine of FIG. 5. Theapplication server 105 is therefore in possession of the blockchainaddress of an account associated with the user. Subsequently, theapplication server 105 performs the routine of FIG. 6 in order toprovide the user with a catalogue of assets. The application server 105sends, at S1001, a revocation attempt to the asset contract 301 in theform of an RPC request. The revocation attempt contains data includingthe blockchain address of the user to whom the evidence data relates.

The revocation attempt is received, at S1003, at the asset contract 301.In response to receiving the certification attempt, the asset contract301 checks, at S1005, the cTrust level of the user, and further checks,at S1007, whether the canRevoke privilege has been assigned to the user.In order to check the cTrust level of the user and whether the canRevokeprivilege has been assigned to the user, the asset contract 301 sends amessage to the control contract 401, causing the control contract 401 tosend a message to the asset contract 301 indicating a global cTrustlevel, an asset-specific cTrust level, of the witness, and an indicationof whether the user has revocation rights. In order to be permitted torevoke a certification of evidence, either the global cTrust level ofthe user, or the asset-specific cTrust level of the user, must be atleast as high as the cTrust level of the asset corresponding to theasset contract 301, and the user must also have revocation rights.

If the user is permitted to revoke the certification of evidence, theasset contract 301 sets, at S1009, a revocation flag in thecertification structure corresponding to the user.

The asset contract 301 generates, at S1011, a revocation event on thepublic blockchain 103. Revocation events are used by the applicationserver 105 to decorate catalogues of assets provided to users, asdescribed above with reference to FIG. 6.

In the example of FIG. 10, a user logs into the application server 105with first user device 113 in order to perform a certification evidencedata. In another example, a user performs a revocation of evidence datausing second user device 115 using a browser-based DApp. In thisexample, the steps performed by the application server 105 in FIG. 9 areperformed by the second user device 115. Accordingly, second user device115 maintains an Ethereum wallet such that Ether may be available formaking necessary transactional changes to the public blockchain 103.

Certifications of evidence, and subsequent revocations of suchcertifications, may be queried using certification and revocationevents, as discussed in the example of FIG. 6. Alternatively, a user maysend an RPC request to a specific asset contract stored on the publicblockchain 103, requesting certification data corresponding to aspecific user. In this case, the RPC request includes the blockchainaddress of the account associated with the user for which evidence datais certified. If the user has requested a certification of evidence, theasset contract sends an RPC response including a location at which theevidence data is stored, and indicating whether certification and/orrevocation flags are set in the certification structures of the assetcontract. If the user has not requested a certification of evidence, theasset contract sends an RPC response indicating that the user has notrequested a certification of evidence.

FIG. 11 shows an example in which a user of first user device 113 havingadministrative privileges deploys the control contract 401, along withasset contracts, on the public blockchain 103 using the applicationserver 105. The application server 105 receives, at S1101, usercredentials from the first user device 113. The application server 105requests, at S1103, an access token from the IdP 116 for access to thetaxonomy server 112. The IdP 116 receives the access token request atS1105, and checks, at S1107, whether the user credentials received atS1101 are valid. If the user credentials are valid, the IdP 116generates, at S1109, an access token for access to the taxonomy server112. In this example, the access token is a JWT. The IdP 116 sends, atS1111, a token response to the application server 105. If thecredentials received at S1101 are valid, the token response includes theaccess token generated at S1109. If the credentials received at S1101are not valid, the token response indicates that the credentials are notvalid. The application server 105 receives the token response at S1115and authenticates the access token at S1117.

The application server deploys, at S1119, the control contract 401 onthe public blockchain 103. Deploying the control contract 401 requiresEther to be sent from an account on the public blockchain 103. In thisexample, the account is associated with an Ethereum wallet maintained bythe operator of the application server 105. Initially, the controlcontract 401 stores no user addresses or asset addresses. Deploying thecontrol contract 401 includes storing, in the control contract storage405, the address of a user account associated with the user deployingthe control contract, such that the address becomes the owner address409, and the user becomes the owner of the control contract 401. Asdescribed above, certain operations are only permitted to be performedby the owner of the control contract 401.

When the application server 105 deploys the control contract 401, thecontrol contract 401 is assigned an address on the public blockchain103. The public blockchain 103 sends, at S1121, the assigned address tothe application server 105. The application server 105 receives, atS1123, the assigned address of the control contract 401, and stores theaddress in a configuration file, such that the application server 105can subsequently look up the control contract 401.

The application server 105 requests, at S1125, taxonomy data from thetaxonomy server 112. The taxonomy data includes metadata correspondingto assets. In this example, the metadata for an asset includes the nameof the asset and a unique identifier for the asset. The taxonomy data inthis example further defines a hierarchy of assets. The request fortaxonomy data includes the access token generated at S1109. The taxonomyserver 112 receives, at S1127, the request for taxonomy data andauthenticates, at S1129, the access token using a token authenticationkey maintained by the taxonomy server 112, as mentioned above. Havingauthenticated the access token, the taxonomy server 112 sends, at S1131,taxonomy data to the application server 105.

The application server 105 receives, at S1133, the taxonomy data fromthe taxonomy server 112. As mentioned above, the taxonomy data includesnames and unique identifiers of one or more assets. For each assetidentified in the taxonomy data, the application server 105 deploys, atS1135, an asset contract on the public blockchain, using the name of theasset and the unique identifier for the asset as constructor parameterssuch that the deployed asset contract stores the name and the uniqueidentifier. The deployed asset contract is assigned an address on thepublic blockchain 103. The public blockchain 103 sends, at S1137, theassigned address of the asset contract to the application server 105.The application server 105 sends, at S1139, an RPC request to thedeployed asset contract, the RPC request including the blockchainaddress of the control contract 401. The RPC request causes the assetcontract to set the address of the control contract 401 in the controlcontract address field of the asset contract. The RPC request furthercauses the asset contract to send a message to the control contract 401,which causes the control contract 401 to add the asset address to thecontrol contract storage 405, thereby registering, at S1141, the assetcontract on the control contract.

Once a control contract has been deployed, the owner of the controlcontract (the user who deployed the control contract) may register useraccounts with the control contract, such that for each registered useraccount the control contract stores the blockchain address of the useraccount, and an associated user structure. In this example, registeringwith the control contract includes the user providing the owner of thecontrol contract with identity data, and the user structure includes ahash of the provided identity data as mentioned above.

In the example of FIG. 11, a new control contract is deployed on thepublic blockchain 103. In another example, a control contract alreadyexists on a blockchain, and is updated to include additional assetsidentified in taxonomy data. In this example, the routine of FIG. 11 isadapted to include initial steps in which the existing control contractis queried for existing asset contracts on the blockchain, and theexisting asset contracts are then queried for asset data, including thenames and unique identifiers of the existing asset contracts. Theroutine then follows the steps of S1125-S1141 to deploy additional assetcontracts for any assets identified in the taxonomy data but not yethaving corresponding asset contracts on the blockchain.

Private Chain System

A private distributed ledger may be deployed as a fork of a blockchainproject on a public blockchain, and may be customised for private use.In such a deployment, a mining difficulty level (or equivalentparameters for another consensus algorithm) is configured to avoidresource wastage (e.g. in mining operations), as trust is not a primaryconcern in such a deployment. Using private distributed ledgers for datastorage or processing is generally considered to be against the ethos ofmost distributed ledger applications, in which the decentralised trustmodel is considered to be the primary advantage. However, the applicanthas identified a number of advantages in using private distributedledgers within a data processing system. For example, a privatedistributed ledger offers distributed redundancy across multiple nodes,as well as a verifiable immutable state as a result of the chain ofblocks that comprise the private distributed ledger. Furthermore, theprivate distributed ledger may have an identical virtual machine modelfor contract code execution and identical Application ProgrammingInterfaces (APIs) to the public blockchain.

In some examples, a single entity, such as a corporate entity, maydeploy a system such as the system described above with reference toFIG. 1 in order to associate users with assets relevant to the entity.For example, a corporate entity may wish to maintain a record of assetscorresponding to training outcomes, and a corresponding record ofemployees that have achieved the training outcomes. Such records may befreely available to employees of the corporate entity, or to a subset ofemployees, but may also be of interest to other entities or individualsnot employed by the corporate entity. Such records, and evidence datarelating to certification of such records may, however, be private, andthe corporate entity may wish to exert centralised control over who ispermitted to access the corresponding data.

FIG. 12 shows a second example of a system for storing and processingdata in accordance with the present invention. The system includeson-site components, which are shown within the dashed box 1201, andoff-site components, which are shown outside the dashed box 1201. Theon-site components are connected by a private network. In this example,the on-site components are operated by single corporate entity, and arelocated at the same physical site. The private network in this exampleis a Local Area Network (LAN). In other examples, on-site components arelocated across several different physical sites, and the private networkis a Virtual Private Network (VPN).

The on-site components include computing devices acting as nodes to hosta private distributed ledger 1203 (referred to hereafter as the privateblockchain 1203). The private blockchain 1203 in this example is aprivate Ethereum blockchain. The private blockchain 1203 stores acontrol contract and asset contracts similar to those described abovewith reference to FIGS. 3 and 4. In this example, the trust level datastored by an asset contract on the private blockchain 1203 includesvTrust level data. The vTrust level data stored by the asset contractincludes a vTrust level for the asset, and may also include vTrustlevels for specific certifications of evidence stored on the assetcontract. In this example, during certification of evidence on theprivate blockchain 1203, a user performing the certification may set avTrust level that is higher than a default vTrust level for the asset.As will be described in more detail hereafter, the vTrust levels of anasset and/or certification may be compared with vTrust levels of a userin order to determine whether a user of an off-site user device ispermitted to view evidence associated with a certification of an asset.

The on-site components include an on-site application server 1205, whichis configured to communicate via the private network with nodes of theprivate blockchain 1203. The on-site application server 1205communicates with the nodes of the private blockchain 1203 by means ofexchanging Remote Procedure Call (RPC) requests and responses. In thisexample, the on-site application server 1205 uses the EthereumJSON-RPC-2.0 protocol to communicate with nodes of the privateblockchain 1203. The on-site application server 1205 is operable todeploy contracts on the private blockchain 1203, and to maketransactional changes to contracts stored on the private blockchain1203, as will be described in detail hereafter. One function of theon-site application server 1205 is to deploy a control contract on theprivate blockchain 1203, and asset contracts controlled by the deployedcontrol contract. Other functions of the on-site application server 1205include altering global and asset-specific trust levels stored on thedeployed control contract. The on-site application server 1205 is alsoconfigured to communicate with an on-site evidence store 1207 andmultiple on-site user devices, including the on-site user device 1108.In this example, the on-site evidence store 1207 includes a databaselocated at the physical site of the on-site components. The on-siteevidence store 1207 is used to store evidence data indicating that usersare associated with assets corresponding to asset contracts stored onthe private blockchain 1203. The on-site application server 1205provides access management services on behalf of users, including theuser of the on-site user device 1108. The on-site application server1205 is configured equivalently to the application server 105 shown inFIG. 2, and is operable to perform functions with respect to the privateblockchain 1203 equivalent to those described with respect to the publicblockchain 103 in FIGS. 6, 7, 8, 10, and 11.

The on-site components further include a firewall server 1209 forcontrolling communications with computing devices outside the privatenetwork 1201. The firewall server 1209 is configured to communicate withnodes of the private blockchain 1203, and with an audit server 1211. Thefirewall server 1209 communicates with the nodes of the privateblockchain 1203 using the Ethereum JSON-RPC-2.0 protocol. The on-sitecomponents also include a private IdP 1216.

The off-site components include multiple off-site user devices,including first off-site user device 1213 and second off-site userdevice 1215. In this example, first off-site user device 1213 and secondoff-site user device 1215 are desktop computers. Other user devices maybe laptop computers, tablet computers, smart phones, or any other typeof user device capable of communicating with an application server usingHyperText Transfer Protocol Secure (HTTPS). First off-site user device1213 is configured to communicate with an off-site application server1217. In some implementations of the present example, the off-siteapplication server 1217 is a cloud-hosted virtual application server,for example a virtual application server provided by Amazon WebServices® (AWS). In other implementations, the off-site applicationserver 1217 is a physical server. The off-site application server isfurther configured to communicate with the private IdP 1216, and apublic IdP 1218.

The off-site application server 1217 provides an application interfaceto the first off-site user device 1213, and is configured to communicatewith the private blockchain 1203 via the firewall server 1209 by meansof exchanging Remote Procedure Call (RPC) requests and responses. Inthis example, the off-site application server 1217 uses the EthereumJSON-RPC-2.0 protocol to communicate with the firewall server 1209. Theoff-site application server 1217 communicates with the firewall server1209 using equivalent RPC calls and responses to those used tocommunicate with a blockchain node. The off-site application server 1217provides access management services on behalf of the user of the firstoff-site user device 1213, which include managing Ethereum key pairs andrequesting access tokens from the private IdP 1216 and the public IdP1218. In this example, access tokens are used to provide identityinformation to the firewall server 1209 on behalf of users, includingthe user of first off-site user device 1213. The private IdP 1216 storesa list of users associated with accounts on the private blockchain 1203,along with blockchain addresses of the associated accounts. The off-siteapplication server 1217 also communicates with a taxonomy server 1212,which provides taxonomy services that include modelling attributes ofusers. The taxonomy server 1212 in this example is a GraphQL server.Second off-site user device 1215 is configured with a browser-basedDecentralised Application (DApp), and communicates with the firewallserver 1209 using the Ethereum JSON-RPC-2.0 protocol. Second off-siteuser device 1215 performs access management locally using alocally-managed wallet containing an Ethereum key pair and havingassociated Ether.

The firewall server 1209 processes data contained within RPC responsessent from nodes of the private blockchain 1209 to the off-siteapplication server 1217, or sent from nodes of the private blockchain1209 to second off-site user device 1215. Examples of processing datacontained within an RPC response include redacting the data and hashingthe data, as will be described hereafter.

As shown in FIG. 13, the firewall server 1209 stores a master controlroutine 1301. The master control routine 1301 is configured to callsubroutines including RPC data processing routines 1303, audit routines1305, and request handling routines 1307. The RPC data processingroutines 1303 include redaction routines 1309, hashing routines 1311,and encryption routines 1313. The master control routine 1301 calls theRPC data processing routines 1303 in order to process data containedwithin RPC responses sent from nodes of the private blockchain 1203 tothe off-site application server 1217, or to the second off-site userdevice 1215. The master control routine 1301 calls the request handlingroutines 1307 in response to receiving RPC requests from off-siteapplication server 1217, or the second off-site user device 1215. Thefirewall server 1209 further stores a digital signature key 1315, whichis a private cryptographic key used for signing RPC responses. Thefirewall server 1209 further stores a token authentication key 1317,which is used for authenticating access tokens received from the privateIdP 1216, as will be described hereafter.

As shown in FIG. 14, the off-site application server 1217 stores amaster control routine 1401. The master control routine 1401 isconfigured to call subroutines including access management routines 1403and blockchain routines 1405. The access management routines 1403include identity management routines 1407. The master control routine1401 calls the identity management routines 1407 in order to requestaccess tokens from the private IdP 1216 and the public IdP 1218, and toauthenticate access tokens from the public IdP 1218. The master controlroutine is configured to call the blockchain routines 1405 in order tosend requests to the firewall server 1209 to invoke methods on theprivate blockchain 1203. The off-site application server 1217 furtherstores token authentication keys 1409, which are used for authenticatingaccess tokens received the public IdP 1218.

FIG. 15 shows an example of a firewall management contract 1501 storedon the nodes of the private blockchain 1203. The firewall managementcontract 1501 contains firewall management contract code 1503 andfirewall management contract storage 1505. The firewall managementcontract storage 1505 includes, for each user associated with an accounton the private blockchain 1203, the blockchain address of the useraccount and an associated data structure for the user. The associateddata structure for the user includes data indicative of global andasset-specific filter rules associated with the user. Filter rules areused by the firewall server 1209 to determine whether to process RPCresponse data received from the private blockchain 1203 in advance ofsending to an RPC response to the off-site application server 1217 orthe second off-site user device 1215. Examples of filter rules that maybe associated with a user are:

-   -   global read access allow—allows the associated user to access        data stored on any asset contract stored on the blockchain;    -   asset-specific read access allow—allows the associated user to        access data stored by a specific asset contract;    -   redaction on method responses—allows the associated user to        access a subset of the data stored by a specific asset contract;    -   redaction on events—allows the associated user to query a subset        of events from a specific asset contract;    -   encryption on method responses—allows the associated user to        access data stored by a specific asset contract, and encrypts        the returned data;    -   encryption on events—allows the associated user to query a        subset of events from a specific asset contract, and encrypts        the returned data.

In this example, the associated data structure for each user includesvTrust level data. The vTrust level data includes a global vTrust levelfor the user, and may include asset-specific vTrust levels for the user.As will be described in more detail hereafter, the vTrust levels of anasset and/or certification may be compared with vTrust levels of a userin order to determine whether a user of an off-site user device ispermitted to view evidence associated with a certification of an asset.

Other filter rules are envisaged relating to processing of RPC responsedata. In this example, the default filter rule for a user is to denyaccess to data stored by any asset contract stored on the privateblockchain 1203. For cases in which the firewall management contract1501 specifies filter rules for a user, the least restrictive filterrule for a given asset contract takes precedent.

FIG. 16 shows an example in which the off-site application server 1217requests an access token for access to the firewall server 1209 onbehalf of a user. The off-site application server 1209 receives, atS1601, credentials from the first off-site user device 1213. In thisexample, the credentials include a username and a password. The off-siteapplication server 1209 requests, at S1603, an access token from theprivate IdP 1216. The request includes the credentials received atS1601. After receiving the access token request at S1605, the privateIdP 1216 checks, at S1607, whether the credentials are valid. If thecredentials are not valid, the private IdP 1216 sends, at S1609, aresponse to the application server indicating that access to thefirewall server 1209 is denied. In this example, the response is an HTTP303 Forbidden response indicating that no further action will be takenby the off-site application server 1217 regarding the request forfirewall access.

If the credentials are valid, the private IdP 1216 looks up, at S1611, ablockchain address of an account associated with the user. The privateIdP 1216 then generates, at S1613, an access token. In this example, theaccess token is a JWT. The JWT includes header, payload, and signaturefields. The private IdP 1216 uses a cryptographic key to generate thesignature of the JWT by applying a hashing algorithm to data includingthe cryptographic key and a concatenation of the header and the payload.In this example, the HMAC-SHA256 algorithm is used. In other examples,other hashing algorithms may be used. In some examples, the hashingalgorithm is specified in the header of the JWT. In this example, thepayload field of the JWT includes the blockchain address looked up aS1611.

The private IdP 1216 sends, at S1615, the generated access token to theoff-site application server 1217. The off-site application server 1217receives the generated access token at S1617. The off-site applicationserver 1217 includes the access token in subsequent RPC requests sent tothe firewall server 1209. As mentioned above, the firewall server 1209maintains a token authentication key 1317 corresponding to thecryptographic key used by the private IdP 1216 to generate the signatureof the access token, and therefore by applying the same hashingalgorithm to the concatenation of the header and payload of the accesstoken, the firewall server 1209 is able to verify the signature andhence verify that the access token was generated by the private IdP 1216and has not been modified (for example, by a malicious third party).

In the example of FIG. 16, a user logs into the off-site applicationserver 1217 with first off-site user device 1213 in order to requestaccess to data stored on the private blockchain 1203. In anotherexample, a user requests access to data stored on the private blockchain1203 with second off-site user device 1215 using a browser-based DApp.In this example, the steps performed by the off-site application server1217 in FIG. 16 are performed by second off-site user device 1215.

FIG. 17 shows an example in which the firewall server 1209 accesses, onbehalf of a user of first off-site user device 1213, data stored on anasset contract on the private blockchain 1203. The firewall server 1209receives, at S1701, a request for data in the form of an RPC requestfrom the off-site application server 1217. In this example, therequested data includes a list of the blockchain addresses correspondingto users associated with an asset corresponding to an asset contractstored on the private blockchain 1203. In other examples, other data maybe requested from contracts stored on the private blockchain 1203. Inthis example, the RPC request is an eth_call request operable to invokea constant method on the private blockchain 1203. The RPC requestincludes an access token generated by the private IdP 1216, as describedabove with reference to FIG. 16, the access token including a blockchainaddress of an account associated with the user requesting data.

The firewall server 1209 authenticates, at S1703, the access token. Thefirewall server sends, at S1705, a filtering request in the form of anRPC request to one of the nodes of the private blockchain, specifyingthe firewall management contract 1501 on the private blockchain 1203 asa recipient address. The filtering request includes the blockchainaddress associated with the user requesting data. As discussed above,the firewall management contract 1501 stores a list of blockchainaddresses associated with users, and for each stored blockchain addressof a user, the firewall management contract 1501 stores an associatedset of filter rules.

The firewall management contract 1501 receives, at S1707, the filteringrequest from the firewall server 1209. The filtering request causes thefirewall management contract 1501 to search for filter rulescorresponding to the user. The firewall management contract 1501contract sends, at S1709, a filtering response to the firewall server1209. The filtering response indicates whether the user is authorised toaccess the requested data, and whether the firewall server 1209 isrequired to process the requested data before it is returned to theuser. Examples of the firewall server processing the requested datainclude hashing, encrypting, rewriting, and redacting the data.

The firewall server receives, at S1711, the filtering response. Thefirewall server sends, at S1713, an RPC request to a node of the privateblockchain 1203, specifying the asset contract as a recipient address.In response to receiving the RPC request at S1715, the asset contractexecutes, at S1717, a method specified by the RPC request. In thisexample, the asset contract returns the blockchain addresses of allusers associated with the asset corresponding to the asset contract. Theasset contract sends, at S1719, an RPC response to the firewall server1209.

Having received the RPC response at S1721, the firewall server 1209processes the response data at S1723. In this example, processing theresponse data includes redacting the response data such that theredacted response data corresponds to a subset of the data included inthe RPC response.

The firewall server 1209 signs the RPC response, at S1725, using thedigital signature key 1315. The digital signature key 1315 in thisexample is a private key and has a corresponding public key madeavailable to the off-site application server 1217 (and also available tousers by other means, for example on a website maintained by thecorporate entity operating the on-site components). This allows theoff-site application server 1217 to verify that the RPC responsereceived from the firewall server 1209 originated from the firewallserver 1209 and has not been altered, for example by a malicious thirdparty. In this example, the digital signature is included in an HTTPresponse header of the RPC response. In other examples, a digitalcertificate may instead be included in an HTTP response header, whichwould similarly allow the off-site application server 1217 to verifythat the RPC response received from the firewall server 1209 originatedfrom the firewall server 1209 and has not been altered. The firewallserver 1209 sends, at S1727, the processed, signed response to theoff-site application server 1217 such that the user of first off-siteuser device 1213 may access the processed response data.

In the present example, the firewall server 1209 sends, to the auditserver 1211, data corresponding to each attempt by a user of an off-sitedevice to access data on the private blockchain 1213. The audit server1211 thereby maintains a record of any such attempts, which isaccessible to the corporate entity operating the on-site components.

In the example above, a user of first off-site user device 1213 requestsdata from the private blockchain 1203 via the off-site applicationserver 1217. In another example, a user of second off-site user device1215 requests data from the private blockchain 1203 using abrowser-based DApp.

Public/Private Chain System

In some examples, a control contract and asset contracts may be deployedon a public distributed ledger as described above. A second controlcontract and asset contracts may also be deployed on a privatedistributed ledger controlled by a private entity, for example acorporate entity, where some of the asset contracts on the privatedistributed ledger correspond to some of the asset contracts on thepublic distributed ledger. A user (for example, an employee of theprivate entity) may be associated with a user account on the publicdistributed ledger and also with a user account on the privatedistributed ledger. The user may be certified on the private distributedledger as being associated with an asset, and may wish to advertise thecertification to certain users outside the private entity. As discussedabove, access to data stored on the private distributed ledger iscontrolled by the private entity, but the private entity may permitcertain users from outside the private entity (for example, contractorsor associates) to view the certification, along with correspondingevidence data relating to the certification.

FIG. 18 shows an extension of the system of FIG. 12 for storing andprocessing data in accordance with the present invention. The systemincludes all of the off-site and on-site components of FIG. 12. Of theon-site components, the public chain 1203 and the firewall server 1209are shown. Of the off-site components, the first off-site user device1213, the second off-site user device 1215, the off-site applicationserver 1217, and the public IdP 1218 are shown. Additionally, in thisexample the off-site application server 1217 and the second off-siteuser device 1215 are each configured to communicate with the publicblockchain 103. The public IdP 1218 stores a list of users associatedwith accounts on the public blockchain 103, along with blockchainaddresses of the associated accounts.

As mentioned above with reference to FIG. 4, the control contract 401 onthe public blockchain 103 has a record 407 of registered privateblockchains, including the private blockchain 1203. In this example, therecord 407 includes a name of the private blockchain 1203, a hash of thegenesis block of the private blockchain 1203, a set of public IPaddresses at which the private blockchain 1203 can be reached (in thisexample, a set of IP addresses at which the firewall server 1209 can bereached, and additionally a set of IP addresses at which the private IdP1216 can be reached), and the blockchain address of a control contractstored on the private blockchain 1203. In other examples, otherinformation identifying a private blockchain may be stored instead of,or as well as, a hash of a genesis block.

Each time a private blockchain is registered, a registration event iswritten to the public blockchain 103. It is possible for users to querythese registration events, and thus to receive information about theregistered private blockchains. Furthermore, the owner of the controlcontract 401 may associate a user account on the public blockchain 103with an address on one or more registered private blockchains, such asprivate blockchain 1203. When the owner associates a private blockchainaddress with a public blockchain address in this way, an event iscreated on the public blockchain 103. These events can then be queried,so that it is possible to find information indicative of any registeredprivate chain addresses associated with a user having an account on thepublic chain 103. In other examples, instead of using events to recordinformation associating private chain accounts of a user with a publicchain account of a user, a user structure stored by a control contracton a public blockchain may include data indicative of private chainaddresses associated with the user.

In addition to events that record information associating privateblockchain addresses with public blockchain addresses, events may bewritten to the public blockchain 103 indicating that evidence had beencertified on a private blockchain. Such events are referred to as proxycertifications. A proxy certification is an event written to the publicblockchain 103, indicating that a user is certified as being associatedwith an asset corresponding to an asset contract stored on a privateblockchain. A proxy certification includes the public blockchain addressof the user, as well as the name of the registered private blockchain onwhich the associated asset contract is stored and an address of theassociated asset contract on the registered private blockchain. Proxycertifications on the public blockchain 103 may be queried in order todetermine whether a user associated with an account on the publicblockchain 103 has been certified as being associated with an asset on aprivate blockchain.

In the example of FIG. 19, the off-site application server 1217generates a catalogue of assets on behalf of a current user of firstoff-site user device 1213, where the current user has an associated useraccount on the public blockchain 103, and also has an associated useraccount on the registered private blockchain 1203. The asset catalogueis decorated with certification events and revocation eventscorresponding to a target user that is of interest to the current user.The current user selects the target user from the list of usersmaintained by the public IdP 1218. In this specific example, the currentuser is a prospective employer and the target user is a prospectiveemployee.

The off-site application server 1217 receives, at S1901, credentialsfrom first off-site user device 1213, the credentials corresponding tothe current user of first off-site user device 1213. The off-siteapplication server 1217 acquires, at S1903, an access token from thepublic IdP 1218. As mentioned above, the public IdP 1218 stores a listof users associated with accounts on the public blockchain 103, alongwith blockchain addresses of the associated accounts. Acquiring theaccess token from the public IdP 1218 involves a routine equivalent tothat of FIG. 5, and accordingly the acquired access token includes theaddress of the user account associated with the current user on thepublic blockchain 103.

Having acquired the access token from the public IdP 1218, the off-siteapplication server 1217 generates, at S1905, a decorated catalogue ofassets corresponding to the target user. Generating a decoratedcatalogue of assets involves a routine similar to that of FIG. 6. Thecertification and revocation events in this example are filteredaccording to the blockchain address of the target user. The applicationserver next queries, at S1907, the public blockchain 103 for proxycertifications. The proxy certifications returned in response to thequery are filtered according to the public blockchain address associatedwith the target user. The off-site application server 1217 decorates, atS1909, the catalogue using the proxy certifications, such that entriesof the catalogue corresponding to assets also indicate whether a proxycertification corresponding to the target user exists on the publicblockchain 103. The off-site application server 1217 sends, at S1911,the decorated catalogue of assets to first off-site user device 1213.

In this example, having received the decorated catalogue of assets, thecurrent user of first off-site user 1213 device requests to viewcertification data stored on the private blockchain 1203 associated witha certification having a corresponding proxy certification on the publicblockchain 103. In response to a request from first off-site user device1213, indicating that the current user requests to view thecertification data, the off-site application server 1217 sends an RPCrequest, at S1913, to the control contract 401 stored on the publicblockchain 103, requesting a set of public IP addresses at which theprivate blockchain 1203 can be reached, along with the blockchainaddress of a control contract stored on the private blockchain 1203. TheRPC request includes the name of the registered private blockchain 1203,as indicated by the proxy certification. The control contract 401returns a set of public IP addresses at which the firewall server 1209can be reached, along with the blockchain address of the controlcontract stored on the private blockchain 1203. In this example, thecontrol contract 401 further returns a set of public IP addresses atwhich the private IdP 1216 can be reached.

The off-site application server 1217 queries, at S1915, the publicblockchain 103 for an address on the private blockchain 1203 of a useraccount associated with the target user. As discussed above, this ismade possible by the fact that when the owner of the control contract401 associates a private blockchain address of a user account with apublic blockchain address of a user account, an event is created on thepublic blockchain 103.

Having acquired sets of public IP addresses at which the firewall server1209 and the private IdP 1216 can be reached, along with the privateblockchain address of a control contract on the private blockchain 1203,the off-site application server 1217 acquires, at S1917, an access tokenfor access to the firewall server 1209. Acquiring an access token foraccess to the firewall server 1209 involves a routine equivalent to thatof FIG. 16 and in this example requires the current user to enter a setof credentials for access to the firewall server 1209. As mentionedabove, the private IdP 1216 stores a list of users associated withaccounts on the private blockchain 1203, along with blockchain addressesof the associated accounts.

The off-site application server 1217 sends, at S1919, an RPC requestwith the asset contract on the private chain 1203 specified as arecipient, requesting certification data corresponding to the proxycertification. The RPC request includes the access token acquired fromthe private IdP 1216 at S1917. The firewall server 1209 authenticatesthe access token using a token authentication key 1317 and sends, atS1921, a corresponding RPC request to the private blockchain 1203. Theasset contract sends an RPC response to the firewall server 1209including certification data indicative of a certification of evidencedata. In this example, the certification data includes the location ofthe evidence data in the on-site evidence store 1207.

The firewall server 1209 queries, at S1923, the filter rules specifiedby the firewall management contract 1501. In particular, the firewallserver 1209 queries the firewall management for the global andasset-specific vTrust levels of the current user. The firewall server1209 also queries the asset contract for vTrust level of thecertification corresponding to the proxy certification. As discussedabove, each certification on the private blockchain 1203 has anassociated vTrust level, which is a minimum vTrust level that must beassigned to a user of an off-site user device in order for the user toview evidence corresponding to a certification on the private blockchain1203. In this example, the asset-specific vTrust level of the currentuser is at least as high as the vTrust level for the certification towhich the proxy certification corresponds, and the current user istherefore permitted to view the evidence data.

The firewall server 1209 processes, at S1925, the RPC response datareceived from the asset contract in accordance with the filter rules. Asmentioned above, in this example the current user has a sufficientlyhigh vTrust level to be permitted to view the evidence data, and henceprocessing the RPC response data does not include total redaction of theresponse data. In this example, processing the response data includesrewriting the response data such that data indicative of the location ofthe evidence data (in this example, a URL corresponding to a location inthe on-site data store 1207) is substituted for a URL associated with anon-site proxy server (not shown) that is accessible by the off-siteapplication server 1217, and through which the application server 1217may access the evidence data. In another example, a current user doesnot have a sufficient vTrust level to be permitted to view evidencedata, and processing the response data includes redaction such that thelocation of the evidence data is not included in the processed responsedata.

The firewall server 1209 signs, at S1927, the processed RPC responseusing the digital signature key 1315 and sends, at S1929, the signed,processed RPC response to the off-site application server 1217. Theoff-site application server 1217 receives the signed, processed RPCresponse at S1931.

In this example, the off-site application server 1217 retrieves, atS1933, the evidence data from the location indicated in the signed,processed RPC response. As mentioned above, the indicated location is aURL associated with the on-site proxy server through which the off-siteapplication server may access the evidence data. The application server1217 sends, at S1935, the retrieved evidence data to first off-site userdevice 1213, such that the current user can view the evidence data towhich the proxy certification corresponds. In other examples, the stepof retrieving evidence data is omitted.

FIG. 20 shows an example in which the off-site application server 1217requests a proxy certification corresponding to a certification of anasset contract on the private blockchain 1203, on behalf of a user offirst off-site user device 1213. The off-site application server 1217receives, at S2001, a proxy certification request from the firstoff-site user device 1213. The proxy certification request includes dataindicative of the private blockchain 1203 on which the user alleges acertification has been performed, and an address on the privateblockchain 1203 of an asset contract to which the alleged certificationrelates. In this example, the proxy certification request includes thename of the private blockchain 1203. The off-site application server1217 sends an RPC request, at S2003, to the control contract 401 storedon the public blockchain 103, requesting a set of public IP addresses atwhich the private blockchain 1203 can be reached. As described above,the set of public IP addresses in this example is a set of public IPaddress at which the firewall server 1209 can be reached.

Having received an IP address at which the private blockchain 1203 maybe reached, the off-site application server 1217 requests, at S2005,access to data stored on the private blockchain 1203 via the firewallserver 1209. In this example, a routine equivalent to the routine ofFIG. 16 is used to grant firewall access and to provide the firewallserver 1209 with a blockchain address associated with the user. Theoff-site application server 1217 queries, at S2007, the existence of acertification on the private blockchain 1203. Having received the queryat S2009, the firewall server 1209 queries, at S2011, the privateblockchain 1203 for a certification event indicating that the allegedcertification exists. The private blockchain 1203 receives the query atS2013. The private blockchain 1203 sends, at S2015, a certificationevent response indicating that the alleged certification event exists onthe private blockchain 1203.

The firewall server 1209 processes, at S2017, the certification eventresponse depending on the filter rules of the firewall server. In someexamples, the filter rules may include total redaction of the responsesuch that no data indicative of the certification is returned to theapplication server. In this example, no redaction is performed and thefirewall server 1209 sends, at S2019, processed response data to theapplication server 1217. The off-site application server 1217 receivesthe processed response data at S2021. Having received the processedresponse data, indicating that the alleged certification exists on theprivate blockchain 1203, the off-site application server 1217 sends, atS2023, an RPC request to a node of the public blockchain 103, therequest having the address of a corresponding asset contract on thepublic blockchain 103 as a recipient address. The RPC request causes theasset contract to issue a proxy certification event on the publicblockchain 103.

The above embodiments are to be understood as illustrative examples ofthe invention. Further embodiments of the invention are envisaged, forexample, the distributed ledger may be based on a Hyperledgerblockchain. It is to be understood that any feature described inrelation to any one embodiment may be used alone, or in combination withother features described, and may also be used in combination with oneor more features of any other of the embodiments, or any combination ofany other of the embodiments. Furthermore, equivalents and modificationsnot described above may also be employed without departing from thescope of the invention, which is defined in the accompanying claims.

The content of this description contains the following numbered clauses:

A data processing system comprising:

-   -   a plurality of computing nodes configured to host a distributed        ledger;    -   a computing device communicatively coupled with one of the        computing nodes; and    -   a data store communicatively coupled with the computing device,    -   wherein the distributed ledger comprises:        -   a plurality of user accounts, each of the plurality of user            accounts having an address on the distributed ledger; and        -   one or more asset contracts, each of the one or more asset            contracts having an address on the distributed ledger,    -   wherein the computing device is operable to provide association        data to a first asset contract of the one or more asset        contracts, the provided association data comprising:        -   an address on the distributed ledger of a first user account            of the one or more user accounts; and        -   data indicative of a first data location in the data store,            and    -   wherein the first asset contract is arranged to:        -   store the provided association data; and        -   in response to a query indicating the first user account,            return the data indicative of the first data location,            thereby to enable access to data stored at the first data            location.

2. The system of clause 1, operable to certify association data storedby a second asset contract of the one of more asset contracts, theassociation data stored by the second asset contract comprising:

-   -   an address on the distributed ledger of a second user account of        the one or more user accounts; and    -   data indicative of a second data location in the data store,    -   wherein certifying the association data stored by the second        asset contract comprises the computing device:        -   sending a first request to the second asset contract for the            data indicative of the second data location, the first            request conveying data indicating the second user account;        -   retrieving data from the indicated second data location for            certification by a first current user of the computing            device; and        -   in response to an input from the first current user            indicating certification of the data retrieved from the            second data location, sending a second request to the second            asset contract, the second request conveying data indicating            certification of the data retrieved from the second data            location, and    -   wherein certifying the association data stored by the second        asset contract further comprises the second asset contract        updating, in response to receiving the second request, the        association data stored by the second asset contract to indicate        that an association of the second user account with data stored        at the second data location is certified.

The system of clause 2, wherein:

-   -   certifying the association data stored by the second asset        contract comprises the second asset contract generating a        certification event on the distributed ledger; and    -   in response to a request for certification events, the        distributed ledger is arranged to return data indicative of the        certification of the association data stored by the second asset        contract.

4. The system of clause 2 or 3, wherein:

-   -   the distributed ledger further comprises a control contract        having an address on the distributed ledger and storing first        trust level data indicative of a trust level of the first        current user, and    -   wherein certifying the association data stored by the second        asset contract comprises:        -   the second asset contract requesting the first trust level            data from the control contract;        -   the control contract sending the first trust level data to            the second asset contract; and        -   the second asset contract determining, using the first trust            level data, that the first current user is permitted to            certify the association data stored by the second asset            contract.

5. The system of any previous clause, operable to revoke a certificationof association data stored by a third asset contract of the one of moreasset contracts, the association data stored by the third asset contractcomprising:

-   -   an address on the distributed ledger of a third user account of        the one or more user accounts;    -   data indicative of a third data location in the data store; and    -   data indicating the certification of the association data,    -   wherein revoking the certification of the association data        stored by the third asset contract comprises:        -   the computing device, in response to an input from a second            current user of the computing device indicating revocation            of the certification of the association data stored by the            third asset contract, sending a third request to the third            asset contract, the third request conveying data indicating            revocation of the certification of the association data            stored by the third asset contract; and        -   the third asset contract updating, in response to receiving            the third request, the association data stored by the third            asset contract to indicate that the certification of the            association data stored by the third asset contract is            revoked.

6. The system of clause 5 dependent on clause 4, wherein the controlcontract stores second trust level data indicative of a trust level ofthe second current user, and

-   -   wherein revoking the association data stored by the third asset        contract comprises:        -   the third asset contract requesting the second trust level            data from the control contract;        -   the control contract sending the second trust level data to            the third asset contract; and        -   the third asset contract determining, using the second trust            level data, that the second current user is permitted to            revoke the certification of the association data stored by            the third asset contract.

The system of clause 5 or 6, wherein:

-   -   revoking the certification of association data stored by the        second asset contract comprises the second asset contract        generating a revocation event on the distributed ledger; and    -   in response to a request for revocation events, the distributed        ledger is arranged to return data indicative of the revocation        of the association data stored by the third asset contract.

8. The system of any previous clause, comprising an Identity Provider(IdP) communicatively coupled with the computing device and storing dataassociating user credentials with addresses of the one or more useraccounts,

-   -   wherein the computing device is operable to:        -   receive user credentials associated with the address of the            first user account; and        -   send the received user credentials to the IdP, and    -   wherein the IdP is operable to:        -   look up, using the user credentials sent by the computing            device, the address of the first user account; and        -   send the address of the first user account to the computing            device.

9. The system of any of clauses 4 to 8, comprising a taxonomy servercommunicatively coupled to the computing device and operable to storetaxonomy data, the taxonomy data comprising data indicating a hierarchyfor the one or more asset contracts,

-   -   wherein:        -   the control contract further stores asset address data            indicating the addresses of the one or more asset contracts;        -   each of the one or more asset contracts stores asset data            comprising a unique asset identifier; and    -   the computing device is operable to:        -   retrieve, from the control contract, the asset address data;        -   retrieve, from the taxonomy server, the taxonomy data;        -   retrieve, from each of the one or more asset contracts            having addresses indicated by the retrieved asset address            data, the asset data; and        -   construct, using the retrieved taxonomy data and the            retrieved asset data, a catalogue of assets corresponding to            the one or more asset contracts.

10. The system of any previous clause, wherein the computing device is avirtual computing device.

11. The system of any previous clause, wherein the data store comprisesa distributed data store.

12. The system of any previous clause, wherein:

-   -   the plurality of computing nodes and the computing device form        part of a private network; and    -   the private network further comprises a firewall server for        controlling communications with computing devices outside the        private network.

13. The system of clause 12, wherein the firewall server is configuredto process data received from one of the plurality of computing nodesand send the processed data to a computing device outside the privatenetwork,

-   -   wherein processing the received data comprises at least one of        redacting, encrypting, and hashing the received data.

14. The system of clause 13, wherein:

-   -   the computing device is a first computing device;    -   the distributed ledger comprises a firewall management contract        having an address on the distributed ledger and storing filter        rule data associating the addresses of one or more of the        plurality of user accounts with filter rules indicating        processing operations; and    -   the firewall server is configured to:        -   receive, from a second computing device outside the private            network, a request for data stored on the distributed            ledger;        -   query, in response to receiving the request for data stored            on the distributed ledger, the firewall management contract            for filter rule data associating an address of a fourth user            account with filter rules indicative of processing            operations, the fourth user account being associated with a            current user of the second computing device;        -   request data stored on the distributed ledger;        -   process, in response to receiving data from the distributed            ledger, the received data in accordance with the indicated            processing operations; and        -   send the processed data to the second computing device.

15. The system of clause 14, comprising a private Identity Provider(IdP) communicatively coupled with the second computing device andstoring data associating user credentials with addresses of the one ormore user accounts,

-   -   wherein the second computing device is operable to:        -   receive user credentials associated with the address of the            fourth user account; and        -   send the received user credentials associated with the            fourth user account to the private IdP, and    -   wherein the private IdP is operable to:        -   look up, using the user credentials sent by the second            computing device, the address of the fourth user account;            and        -   send the address of the fourth user account to the computing            device.

16. The system of any of clauses 12 to 15, wherein the private networkis a virtual private network.

17. A data processing infrastructure comprising:

-   -   a first data processing system as described in any of clauses 4        to 11, wherein the distributed ledger of the first data        processing system is a first distributed ledger; and    -   a second data processing system as described in any of clauses        12 to 16, wherein the distributed ledger of the second data        processing system is a second distributed ledger,    -   wherein the control contract of the first data processing system        stores data identifying the second distributed ledger and is        arranged to return, in response to receiving a request from a        computing device, the data identifying the second distributed        ledger.

18. The infrastructure of clause 17, wherein the control contract of thefirst data processing system is further arranged to, in response toreceiving a request conveying data comprising:

-   -   an address on the first distributed ledger of a fifth user        account;    -   an address on the second distributed ledger of a sixth user        account; and    -   data identifying the second distributed ledger,    -   generate an event on the first distributed ledger, indicating an        association between the address of the fifth user account and        the address of the sixth user account.

19. The infrastructure of clause 18, wherein the second data processingsystem is as described in either of clauses 14 or 15, wherein the secondcomputing device of the second data processing system is communicativelycoupled with one of the plurality of computing nodes of the first dataprocessing system, and is operable to receive data from the firewallserver indicative of a certification of association data stored by afourth asset contract of the one or more asset contracts on the seconddistributed ledger, the association data stored by the fourth assetcontract comprising:

-   -   the address on the second distributed ledger of the sixth user        account; and    -   data indicative of a fourth data location in the data store,    -   wherein the second computing device of the second data        processing system is operable to send a fourth request to a        fifth asset contract on the first distributed ledger, the fourth        request conveying data comprising:        -   the address on the first distributed ledger of the fifth            user account;        -   data identifying the second distributed ledger; and        -   an address on the second distributed ledger of the fourth            asset contract, and    -   wherein the fifth asset contract is configured to generate, in        response to receiving the fourth request, a proxy certification        event on the first distributed ledger, the proxy certification        event comprising:        -   the address on the first distributed ledger of the fifth            user account;        -   the data identifying the second distributed ledger; and        -   the address on the second distributed ledger of the fourth            asset contract,    -   wherein the first distributed ledger is arranged to return, in        response to a query indicating the fifth user account, data        indicative of the certification of the association data stored        by the fourth asset contract.

20. An asset contract for deployment on an electronic privatedistributed ledger system, the asset contract arranged to storeassociation data, the association data comprising:

-   -   an address on the distributed ledger of a user account; and    -   data indicative of a data location in a data store,    -   wherein the asset contract is operable to return, in response to        a query indicating the user account, the data indicative of the        data location, thereby to enable access to data stored at the        data location.

21. The asset contract of clause 20, arranged to:

-   -   update, in response to receiving a request conveying data        indicating certification of the data stored at the data        location, the association data to indicate that an association        of the user account with the data stored at the data location is        certified; and    -   generate a certification event on the distributed ledger,    -   such that the distributed ledger is operable to return, in        response to a request for certification events, data indicative        of the certification of the association data.

22. The asset contract of clause 21, wherein the user account is a firstuser account, and updating the association data to indicate that theassociation of the user account with the data stored at the datalocation is certified comprises:

-   -   retrieving trust level data from a control contract on the        distributed ledger, the trust level data indicating a trust        level associated with a second user account; and    -   determining, using the trust level data, that a user associated        with the second user account is permitted to certify the        association data.

23. The asset contract of clause 21 or 22, arranged to:

-   -   update, in response to receiving a request conveying data        indicating revocation of the certification of the data stored at        the data location, the association data to indicate that the        certification of the association of the user account with the        data stored at the data location is revoked; and    -   generate a revocation event on the distributed ledger,    -   such that the distributed ledger is arranged to return, in        response to a request for revocation events, data indicative of        the revocation of the certification of the association data.

24. The asset contract of clause 23, wherein updating the associationdata to indicate that the certification of the association of the useraccount with the data stored at the data location is revoked comprises:

-   -   Retrieving further trust level data from a control contract on        the distributed ledger, the trust level data indicating a trust        level associated with a third user account; and    -   determining, using the further trust level data, that the user        associated with the third user account is permitted to revoke        the certification of the association data.

25. The asset contract of any of clauses 20 to 24, wherein thedistributed ledger is a first distributed ledger, and wherein the assetcontract is arranged to, in response to receiving a request conveyingdata comprising:

-   -   an address on the first distributed ledger of a seventh user        account;    -   data identifying a second distributed ledger; and    -   an address on the second distributed ledger of a further asset        contract,    -   generate a proxy certification event on the first distributed        ledger, the proxy certification event comprising:    -   the address on the first distributed ledger of the seventh user        account;    -   the data identifying the second distributed ledger; and    -   the address on the second distributed ledger of the further        asset contract.

26. A control contract for deployment on electronic private distributedledger system, arranged to:

-   -   store trust level data indicating a trust level associated with        a first user account on the distributed ledger; and    -   send, in response to receiving a first request from an asset        contract on the distributed ledger, the trust level data to the        asset contract.

27. The control contract of clause 26, further arranged to:

-   -   store asset address data comprising addresses on the distributed        ledger of one or more asset contracts; and    -   send, in response to receiving a second request from a computing        device, the asset address data to the computing device.

28. The control contract of clause 26 or 27, wherein the distributedledger is a first distributed ledger, and wherein the control contractis configured to:

-   -   receive a third request from a first computing device, the third        request conveying data identifying a second distributed ledger;    -   store the data identifying the second distributed ledger,        thereby to register the second distributed ledger; and    -   return, in response to receiving a fourth request from a second        computing device, the data identifying the second distributed        ledger.

29. The control contract of clause 28, arranged to generate, in responseto receiving the third request, a registration event on the firstdistributed ledger.

30. The control contract of clause 28 or 29, arranged to, in response toreceiving a fifth request from a third computing device, the fifthrequest conveying data comprising:

-   -   an address of a second user account on the first distributed        ledger;    -   an address of a third user account on the second distributed        ledger; and    -   data identifying the second distributed ledger,    -   generate an event on the first distributed ledger, indicating an        association of the address of the second user account with the        address of the third distributed ledger.

31. A computing node configured to host a distributed ledger and storingan asset contract as described in any of clauses 20 to 25.

32. The computing node of clause 31, storing a control contract asdescribed in any of clauses 26 to 30.

33. A computing device communicatively coupled with a data store andwith one of a plurality of computing nodes, the plurality of computingnodes configured to host a distributed ledger,

-   -   wherein the distributed ledger comprises:        -   a plurality of user accounts, each of the plurality of user            accounts having an address on the distributed ledger; and        -   one or more asset contracts, each of the one or more asset            contracts having an address on the distributed ledger,    -   wherein the computing device is operable to provide association        data to a first asset contract of the one or more asset        contracts, the provided association data comprising:        -   an address on the distributed ledger of a first user account            of the plurality of user accounts; and        -   data indicative of a first data location in the data store.

34. The computing device of clause 33, operable to:

-   -   send a first request to a second asset contract of the one or        more asset contracts, the first request conveying data        indicating a second user account of the plurality of user        accounts and requesting data indicative of a data location in        the data store;    -   receive a response from the second asset contract indicating a        second data location in the data store;    -   retrieve data from the indicated second data location for        certification by a first current user of the computing device;        and    -   in response to an input from a first current user of the        computing device indicating certification of the data retrieved        from the second data location, send a second request to the        second asset contract, the second request conveying data        indicating certification of the data retrieved from the second        data location.

35. The computing device of clause 33 or 34, operable to send, inresponse to an input from a second current user of the computing deviceindicating revocation of a certification of data stored by a third assetcontract, send a third request to the second asset contract, the secondrequest conveying data indicating revocation of the certification ofdata stored by the third asset contract.

36. The computing device of any of clauses 33 to 35, operable toretrieve, from a control contract stored on the distributed ledger,asset address data indicating addresses on the distributed ledger of theone or more asset contracts;

-   -   retrieve, from a taxonomy server, taxonomy data comprising data        indicating a hierarchy for the one or more asset contracts;    -   retrieve, from each of the one or more asset contracts having        addresses indicated by the retrieved asset address data, the        asset data; and        -   construct, using the retrieved taxonomy data and the            retrieved asset data, a catalogue of assets corresponding to            the one or more asset contracts.

37. A computing device operable to deploy, on a distributed ledger, acontrol contract as described in any of clauses 26 to 30, and one ormore asset contracts as described in any of clauses 20 to 25.

38. A firewall server configured to:

-   -   receive, from a computing device, a request for data stored on a        private distributed ledger;    -   query, in response to receiving the request for data stored on        the private distributed ledger, a firewall management contract        for filter rule data associating an address of a user account        with filter rules indicative of processing operations, wherein        the user account is associated with a current user of the        computing device;    -   request data stored on the private distributed ledger;    -   in response to receiving data stored on the private distributed        ledger, process the received data in accordance with the        indicated processing operations; and    -   send the processed received data to the computing device wherein        processing the received data comprises at least one of        redacting, rewriting, encrypting, and hashing the received data.

39. A firewall management contract for deployment on an electronicprivate distributed ledger system, the firewall management contractarranged to store filter rule data associating addresses of useraccounts on the private distributed ledger with filter rules indicatingprocessing operations,

-   -   wherein the firewall management contract is arranged to send to        a firewall server, in response to a query from the firewall        server indicating an address of a user account on the private        distributed ledger, filter rule data associating the address of        the user account with filter rules indicating processing        operations.

What is claimed is:
 1. A system comprising: a plurality of computingnodes hosting a private distributed ledger, the private distributedledger comprising: a plurality of user accounts each having an addresson the private distributed ledger; and a firewall management contractstoring filter rule data associating the addresses of at least some ofsaid user accounts on the private distributed ledger with respectivefilter rules for handling requests for data stored on the privatedistributed ledger; and a firewall server arranged to: receive, from acomputing device, a request for data stored on the private distributedledger, the request indicating an address of a first user account of theplurality of user accounts; and in response to receiving said request:send a query to the firewall management contract for first filter ruledata associated with the address of the first user account; receive aresponse from the firewall management contract; and process the requestfor data in accordance with the response from the firewall managementcontract.
 2. The system of claim 1, wherein: the response from thefirewall management contract indicates that a user associated with thefirst user account is permitted to access the requested data; andprocessing the request for data in accordance with the response from thefirewall management contract comprises providing the computing devicewith access to the requested data from the private distributed ledger.3. The system of claim 2, wherein providing the computing device withaccess to the requested data comprises: signing the requested data usinga digital signature key; and sending the signed data to the computingdevice.
 4. The system of claim 1, wherein: the response from thefirewall management contract indicates a first set of processingoperations comprising at least one of redacting, rewriting, encrypting,and hashing the retrieved data; and processing the request for data inaccordance with the response from the firewall management contractcomprises: retrieving the requested data from the private distributedledger; processing the retrieved data using the first set of processingoperations; and sending the processed retrieved data to the computingdevice.
 5. The system of claim 1, wherein the private distributed ledgercomprises one or more asset contracts each having an address of theprivate distributed ledger and each storing association data indicativeof a respective one or more of the plurality of user accounts, whereinthe request for data is a request for data stored in association withone of the one or more asset contracts.
 6. The system of claim 5,wherein the respective filter rules associated with at least some of theuser accounts include asset-specific filter rules applicable only todata stored in association with specific asset contracts.
 7. The systemof claim 5, wherein the requested data includes addresses on the privatedistributed ledger of one or more user accounts indicated in theassociation data stored by said one of the plurality of asset contracts.8. The system of claim 5, wherein: the firewall management contractstores trust level data indicating trust levels associated with at leastsome of the plurality of user accounts, including a first trust levelassociated with the first user account; said one of the one or moreasset contracts stores trust level data indicating a second trust level;processing the request for data in accordance with the response from thefirewall management contract comprises processing the request for datain dependence on a comparison between the first trust level and thesecond trust level.
 9. The system of claim 5, further comprising a datastore, wherein the association data stored by said one of the one ormore asset contracts for the first user account indicates a datalocation in a data store; the request is for data indicating the datalocation in the data store.
 10. The system of claim 1, wherein: thecomputing device is an application server communicatively coupled to oneor more user devices; and the computing device is arranged to send saidrequest for data on behalf of one of the one or more user devices. 11.The system of claim 1, wherein, in the event that the response from thefirewall management contract indicates that no filter rule data isstored in association with the address of the first user account, thefirewall server is arranged to apply a default filter rule of denyingthe computing device with access to the requested data.
 12. The systemof claim 1, wherein, in the event that the response from the firewallmanagement contract indicates one or more filter rules stored inassociation with the address of the first user account, the firewallserver is arranged to apply a least restrictive of the indicated one ormore filter rules.
 13. The system of claim 1, wherein said plurality ofcomputing nodes is a first plurality of computing nodes, the systemfurther comprising an application server communicatively coupled to thefirst plurality of computing nodes via the firewall server and furthercommunicatively coupled to a second plurality of computing nodes hostinga public distributed ledger, wherein the application server is arrangedto deploy a control contract on the public distributed ledger, where thecontrol contract stores data identifying the private distributed ledgerand is arranged to return, in response to receiving a request from acomputing device, the data identifying the private distributed ledger.14. The system of claim 13, wherein the deployed control contract isfurther arranged to, in response to receiving a request indicating: anaddress on the public distributed ledger of a public user account; anaddress on the private distributed ledger of a private user account; anddata identifying the private distributed ledger, store information onthe public distributed ledger, indicating an association between theaddress of the public user account and the address of the private useraccount.
 15. The system of claim 14, wherein the first applicationserver is a first application server, the system further comprising: adata store; and a second application server communicatively coupled withthe data store and with the first plurality of computing nodes, wherein:the private distributed ledger comprises one or more asset contractseach having an address of the private distributed ledger and eachstoring association data indicative of a respective one or more of theplurality of user accounts, said one or more asset contracts including afirst asset contract; the first application server is arranged to deploya second asset contract on the public distributed ledger associated withthe first asset contract on the private distributed ledger; the secondapplication server is arranged to receive data from the firewall serverindicative of a certification of association data stored by the firstasset contract, the association data comprising: the address on theprivate distributed ledger of the private user account; and dataindicative of a data location in the data store; the second applicationserver is further arranged to send a proxy certification request to thesecond asset contract, the proxy certification request conveying datacomprising: the address on the public distributed ledger of the publicuser account; data identifying the private distributed ledger; and anaddress on the private distributed ledger of the first asset contract;and the second asset contract is configured to generate, in response toreceiving the proxy certification request, a proxy certification eventon the public distributed ledger, the proxy certification eventcomprising: the address on the public distributed ledger of the publicuser account; the data identifying the private distributed ledger; andthe address on the private distributed ledger of the first assetcontract.
 16. A firewall server configured to: receive, from a computingdevice, a request for data stored on a private distributed ledger, therequest indicating an address of a user account on the privatedistributed ledger; send a query, in response to receiving said request,to a firewall management contract on the private distributed ledger forfilter rule data associated with the address of the user account on theprivate distributed ledger; and receive a response from the firewallmanagement contract; and process the request for data in accordance withthe response from the firewall management contract.
 17. The firewallserver of claim 16, wherein: the response from the firewall managementcontract indicates that a user associated with the first user account ispermitted to access the requested data; and processing the request fordata in accordance with the response from the firewall managementcontract comprises providing the computing device with access to therequested data from the private distributed ledger.
 18. The firewallserver of claim 17, wherein providing the computing device with accessto the requested data comprises: signing the requested data using adigital signature key; and sending the signed data to the computingdevice.
 19. The firewall server of claim 16, wherein: the response fromthe firewall management contract indicates a first set of processingoperations comprising at least one of redacting, rewriting, encrypting,and hashing the retrieved data; and processing the request for data inaccordance with the response from the firewall management contractcomprises: retrieving the requested data from the private distributedledger; processing the retrieved data using the first set of processingoperations; and sending the processed retrieved data to the computingdevice.
 20. A non-transient storage medium comprising machine-readableinstructions which, when executed by a plurality of computing nodeshosting a private distributed ledger, cause the plurality of computingnodes to deploy a smart contract on the private distributed ledger,wherein the deployed smart contract is arranged to: store filter ruledata associating addresses of user accounts on the private distributedledger with filter rules for handling requests for data stored on theprivate distributed ledger; and in response to receiving a query from afirewall server indicating an address of a first user account on theprivate distributed ledger, send a response to the firewall serverindicative of a first set of filter rules associated with the address ofthe first user account.